-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vite test ci #1718
vite test ci #1718
Conversation
@patricklx I don't see this running in CI 🤔 are you just working on this to be able to run tests locally? |
the target is to be able to run it in ci. this is just the setup for it. |
@mansona also tests will not work without
unless we use ember-source 5.6 beta |
So everything happens in scenario-tester which you can see in |
i might need to extract more from my other PR to make this work |
If you could setup the scenario, then i can fix the rest :) |
ca4d35d
to
616ddf8
Compare
packages/core/src/module-resolver.ts
Outdated
@@ -542,12 +542,22 @@ export class Resolver { | |||
} | |||
|
|||
private *componentJSCandidates(inPackageName: string) { | |||
const extensions = ['.ts', '.gjs', '.gts']; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
vite can handle this files. webpack can also already handle ts files, for gjs/gts a loader could be added
packages/vite/src/template-tag.ts
Outdated
let resolution = await this.resolve(id, importer, { | ||
skipSelf: true, | ||
}); | ||
// prevent resolve loop during vite build |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this parts are only needed during vite build. otherwise it will hang
b00cd4f
to
abd8bbb
Compare
@mansona found a fix for windows. |
cdb9a41
to
fef309d
Compare
046eaeb
to
13bc884
Compare
@mansona this is ready and also shows that its working while also building cached deps |
d06ba7b
to
212eb9a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding the CI test for vite is great. But that can be one PR by itself. The tests in vite-app
are already passing on main, so no other changes should be needed to enable the tests in CI.
To make these other changes to core features like PackageCache or module-resolver we need tests showing why they're needed, and to ensure we don't break those cases in the future.
The tests where not really testing much. Only that it loads... There where issues with decorators and vite build was also not working.
|
@@ -30,6 +30,9 @@ export function esBuildResolver(root = process.cwd()): EsBuildPlugin { | |||
let resolution = await resolverLoader.resolver.resolve(request, defaultResolve(build, kind)); | |||
switch (resolution.type) { | |||
case 'found': | |||
if (resolution.result?.path?.includes('rewritten-app')) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mansona I i think i found the real reason we have the optimizer issue.
We call context.resolve in the default resolve here 0aafe02#diff-a6c8071691a61acc68be864b34d3f338fd92e9bf5217c2d12403ac6029bca885R130
with the full absolute path.
which then goes to the vite dep:scan plugin which marks it as external here: https://github.com/vitejs/vite/blob/main/packages/vite/src/node/optimizer/scan.ts#L681
so either we do not call that and check if the id is already resolved in the default resolve
or use e.g resolve from npm or unmark them as external here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i also created a PR on vite as i think its a vite bug: vitejs/vite#15402
lets see
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Btw, this was working in windows without issues... Will verify later again why this is. I suspect the generated path has somr difference in slashes
de8a7d6
to
94977ab
Compare
packages/core/src/module-resolver.ts
Outdated
let resolution = this.nodeResolve( | ||
`${target.packageName}${candidate.prefix}${target.memberName}${candidate.suffix}`, | ||
target.from | ||
); | ||
if (resolution.type === 'real') { | ||
hbsModule = resolution.filename; | ||
hbsModule = candidateSpecifier; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is similar to what we did in #1648. Both are cases where we were rewriting requests to absolute paths, which ends up looking to vite like the user actually typed an absolute path in their import, which gets different behavior than a normal relative- or package-name import.
In this case when we successfully resolve a specifier to a component file to check that it exists, rather than rewriting the request to point directly at that file we rewrite the request to use the specifier that we just successfully resolved.
(This duplicate resolving is only needed when supporting the ambiguity of loose-mode templates. As people migrate to template tag they stop needing it.)
adds ci tests for vite dev